SIP Device Capabilities

System-generated, protected field. Indicates the number of the SIP Device Capabilities profile that you want to edit.

NOTE: SIP Device Capabilities profile number 65 and up are pre-configured for specific Mitel SIP devices.

Enter a meaningful name to describe the type of SIP devices assigned to this number. The Comment can be up to 15 characters in length.

Blank

Select the network element that is being used as the Outbound Proxy Server for SIP devices. The Outbound Proxy Server will then be added to the Trusted Domains for Registration.

The default is to leave this field blank, which means that no Outbound Proxy Server is deployed between SIP devices and MiVoice Business.

Blank

Select Yes to enable only if the SIP endpoint is providing location information to the MiVoice Business.

No

Recommend setting: 'Yes'. The original default value was 'No', but most current SIP phones handle multiple calls well and should maintain information about calls in progress, making use of transfer and conference features on the phone if available.

Phones that do not support conferencing can still in most cases use the Conference Call capability of the MiVoice Business, using the appropriate Feature Access Code.

No **

Some SIP phones do not support the SUBSCRIBE method for message waiting indication (MWI).

Select Yes to allow NOTIFY messages carrying MWI status to be generated without subscription. Select No to require subscription.

No

Select Yes to enable support for the Callback, Camp-on, and Busy Override features on these devices.

There is additional system programming required to enable these features. Use the links above to access programming details.

NOTE: Enabling this option prevents cut-through audio and pre-recorded messages that may be played from a Central Office. Instead, the user will have access to MiVoice Business Features, such as Callback, Camp-on and Busy Override and hear locally generated Busy or Alerting tones.

No

Indicates whether to allow devices only with TLS to register and place calls.

No

When set to 'Yes', MiVoice Business allows the device to negotiate more than one active media description line (m-line) for the Session Description Protocol. For devices capable of negotiating multiple m-lines, such as audio, image, video, and applications, the recommended setting is 'Yes'.

NOTE: For Secure Real-time Protocol (SRTP) negotiations generally this option is enabled.

No **

Select 'Yes' to allow the media source to be switched using an UPDATE message prior to the call being answered.

NOTE: Enable this option only if the SIP set or trunk supports early media negotiation. See RFC 3311 for details.

No **

The default 'Yes' indicates that the device is to be used for unencrypted media only (either the device is not capable or not configured to use Secure Real-time Protocol [SRTP]). This is the same mode (unencrypted) that devices used in pre-7.0 MiVoice Business releases.

If you want the SIP devices to allow SRTP encryption, set this option to 'No' and option Allow Device To Use Multiple Active M-Lines to 'Yes'. This is necessary because many SIP implementations use two or more m-lines to negotiate either SRTP or non-SRTP (one m-line for each). The System Option "Voice/Video SRTP Encryption Enabled" is also required to be set for SRTP to be negotiated.

If this option is set to "No", calls may negotiate as either SRTP or non-SRTP, depending on the capabilities of the devices that are being connected.

See Voice Streaming Security for more information.

Yes

Select 'Yes' only if communicating with a MiVoice Border Gateway. This enables proprietary encryption to be enabled if SRTP is not negotiated.

No

Select 'Yes' to always insert SDP into the initial Invite message. This option allows inter-working with SIP devices that require SDP in the Initial Invite. In some situations, MiVoice Business already includes SDP in the initial invite. The forced SDP may contain a default ‘inactive’ SDP if the SDP is not available at call setup time. If the real SDP is not available, a renegotiation is necessary to get media working.

No

Select "Yes" to improve interoperability with SIP systems that adhere to RFC 3960 and do not always provide audio when sending SDP information in the 18x messages. As a result, the device placing the call may hear silence. With this option enabled, the SDP Answer is ignored during ringback and local ringback tone is provided to the device placing the call. Once the call is answered the media is connected.

No

Select the addressing type (ipv4, ipv6, dual-anat, or dual-altc) for SDP. For SIP devices that support dual media (IPv4 and IPv6) with RFC 4091 or RFC 4092, select dual-anat (Alternative Network Address Type). For SIP devices that support dual media (IPv4 and IPv6) with RFC 6947, select dual-altc (Alternate Connectivity Attribute).

ipv4

Recommended setting: 'Yes'. Most vendors expect just one Offer/Answer exchange in the initial Invite transaction. If the device can begin a second offer in the 200ok and expects a response, set this option to 'No'.

No **

Select 'Yes' to prevent the MiVoice Business from making a codec selection on a list of codecs in the received SDP before sending an SDP Answer. Select 'No' to allow the MiVoice Business to apply a default policy to make an audio/image codec selection before sending an SDP Answer.

No

Select 'Yes' to prevent sending SDP renegotiation messages to the peer device when the peer initiated the hold request. In some cases the MiVoice Business may attempt renegotiations while on hold. Some devices may become confused and prevent the call from being retrieved. Set this option to Yes if issues are detected.

No

Recommended setting: 'Yes'. IP Address 0.0.0.0 is the deprecated indicator of hold. When this option is set to 'Yes', the media signaling includes the direction indicators, such as ‘sendonly’, ‘inactive’, etc., as well as the real IP address. When this option is set to 'No', in some cases it can prevent audio from being available when prompts or music-on-hold is being played to specific devices, which require knowledge of the transmitters IP address.

No **

Recommended setting: 'Yes'. This option forces the use of the same codec (for example, G.729) in both incoming and outgoing directions and prevents the possible media failure.

When an SDP Answer is received with a list of codecs with a different ordering, it can be unclear which codec will be used in either direction. If MiVoice Business detects this situation, this option will send a Re-invite with a single codec to ensure that there is no misunderstanding.

No **

Select 'Yes' to treat identical SDP offers received in the same session as a session refresh instead of renegotiating media. This is the RFC recommendation. Devices should increase the session-version when modification is made to SDP session data. The default is still 'No' because not all vendors adhere to this recommendation and usually this is the safer option.

The interop process should detect whether the device increments the session-version as expected or not, and set this option accordingly. The drawbacks to renegotiating on a duplicate offer is the restart of RTP streaming and possible change of the media attributes, which may not be expected by the device.

No

Recommended setting for most customers: 'Yes'. During a transfer it is possible to send a renegotiation request to a MiVoice IP Phone to change the endpoint it is streaming to. This option is used to determine when the renegotiation request should be answered.

For some SIP phones the best option is to answer immediately rather than wait for the renegotiation to complete since this might take slightly longer. If MiVoice Business answers too early, it will cause a second renegotiation to connect the user to the final destination. 

No **

Select Yes to enable a CTI application to hold and retrieve calls on a SIP endpoint using the hold and talk event packages. This option is enabled only on SIP endpoints that support the hold and talk event packages.

No

Recommended setting: 'No'. With this setting, MiVoice Business provides the actual direction attribute ‘inactive’ instead of pretending media is available when it is not.  

While media connections are transitioning (hold/transfer/conference, etc.), or in some cases at call setup, the media may be temporarily unavailable causing MiVoice Business to send an inactive SDP.

If this option is set to 'Yes', MiVoice Business will instead attempt to use the IP address 0.0.0.0 or mark streams as sendonly/recvonly to avoid the use of inactive, which is not supported by some SIP devices.

Yes **

Recommended setting: 'Yes'. This setting allows the system to update SIP phone displays with connected party name and number information during transfers, conferences, and call forwarding scenarios.

No **

Indicates the type addressing for resiliency signalling.

NOTES:

• This parameter is disabled for 5505 and 5610 IP phones.

• For cMiVB, regardless of this option's setting, FQDNs are used for resiliency.

No

Yes (for cMiVB only)

Select 'Yes' to disable the use of reliable provisional responses (PRACK) on outgoing and incoming calls. However, an incoming call that uses the Require header may negotiate PRACK despite this option being enabled. PRACK is useful for early-media negotiations and should be used if supported.

NOTE: This option takes precedence over the "Require Reliable Provisional Responses on Outgoing Calls" option.

No

Select 'Yes' to disable the insertion of "User-Agent" headers in Request and "Server" headers in Response messages. This option should be enabled only if the product has known deficiencies which place the system at risk of attack.

No

A mid-call feature, such call park, can be activated on a SIP device by sending the feature access code in a REFER message (RFC3515). This is essentially the same as performing an unattended transfer to a feature access code. In some cases, mid-call features such as call park with page will renegotiate a new media stream to the device as part of the feature functionality. Unfortunately most implementation react to a successful REFER response by assuming the call is to be removed from the set.

If this option is set to Yes, then a 420 Bad Request is sent in response to a successful REFER in order to force the device to keep the call active. In the event of a failure, a 603 Decline message is sent. The use of this option may cause a SIP device to play an error tone or display an error message even when the feature has succeeded.

If this option is set to No, then in the success case the REFER is processed properly and the message/sipfrag body defined by RFC 3515 is used to relay information on the persistence of the call.

No

Select Yes to use the "sips:" (Secure SIP) scheme to signal secure (TLS) SIP messaging. Select No to use the "sip:" signaling scheme, where security is indicated by the "transport=TLS" parameter.

No

Enables delivering Out-of-Band DTMF from a MiVoice Business system to a SIP service without interrupting audio playback.

Select RFC 4733 DTMF to deliver Out-of-Band DTMF in the audio playback, using RFC 4733 formatted digits. This mode causes interruptions in the audio playback.

Select SIP INFO dtmf-relay to deliver Out-of-Band DTMF through SIP INFO messages in the application/dtmf-relay content-body. This mode does not cause interruptions in the audio playback.

RFC 4733 DTMF

Select 'Yes' to enable the Multilingual Name Display feature for a specific SIP device. This option will activate only if the 'Multilingual Name Display' System Option is enabled. Selecting 'No' for this option does not disable the feature for the whole system - only for the selected device capability number.

No

Select Yes to override the headers normally used to provide auto-answer functionality. The replacement header is specified below, in the "Override Auto-Answer Headers With" field.

No

If "Override Auto-Answer Headers" is set to "Yes," enter the SIP auto-answer header. For standard SIP devices that support RFC 5373, enter "Answer-Mode: Auto". For non-standard SIP devices, enter the appropriate proprietary header.

Blank

Select Yes to include the Q.850 cause code in the Reason Header field of the CANCEL, BYE, 3xx, 4xx, 5xx, and 6xx SIP messages. See RFC 3326 and RFC 6432.

No

Select Yes to omit the word "anonymous" from call setup messages for private calls. Thus, instead of "John Doe - Anonymous" the called party sees only "John Doe" displayed on their phone (or "Private" instead of "Private - Anonymous" if both name and number are marked private).

No

Recommended setting: 'Yes'. This setting requires the use of reliable provisional responses (PRACK, RFC 3262) on outgoing calls. Unless required, most device will not default to use PRACK, allowing for early-media negotiations.

NOTE: Enable this option only for SIP devices that support the PRACK method. This option has no effect if it is enabled and "Disable Reliable Provisional Responses" is also enabled.

No **

Select 'Yes' to omit redirection headers (Diversion and History-Info Headers for Call Forwarding and Referred-By Header for Transfer) in call setup messages. This option is provided for users who do not want their phones to display this information on calls forwarded or transferred to them by MiVoice Business.

No

Select 'Yes' to enable sending the P-Asserted Identity header within SIP messages. This option is used to convey identity information both at call setup and during a call and is often used to update display information on SIP phones. This header is omitted when the callers information is private.

Yes

Select 'Yes' to include the Call Leg Call ID within the SIP trunk messages exchanged between MiVoice Business and third-party applications. This ID is always included in MiVoice Business-based MiTAI events, so enabling this field allows for SIP sessions to be aligned with MiTAI events.

A new ID will be generated for each call. The header will be in the Invite message - for outgoing calls. For incoming calls, it will be in the 18x message and, if answered, in the 200 OK message OR in a clearing message, such as 3xx, 4xx, 5xx, 6xx (not authentication 401/407).

No

Select Yes to insert the "user=phone" parameter into SIP URIs.

No

Recommended setting: 'Yes'. This setting allows distinctive ring tones for internal calls, external calls, and callbacks to SIP phones.

This option is safe and provides additional value for phones that use it.

No **

Enter a text string for the internal ring tone. The string must match the Alert-Info header for the ring tone supported by the SIP device.

;info=alert-internal

Enter a text string for the external ring tone. The string must match the Alert-Info header for the ring tone supported by the SIP device.

;info=alert-external

Enter a text string for the callback ring tone. The string must match the Alert-Info header for the ring tone supported by the SIP device.

;info=alert-priority

This field sets the minimum negotiated time period allowed between Register requests to the primary ICP and secondary ICP. The range is from 120 to 3,600 seconds.

CAUTION: Frequent Register requests from large numbers of SIP devices can significantly degrade system performance. Therefore, we recommend that the Minimum Registration Period be set to no less than the default of 300 seconds. Note that in cases where there are few SIP devices, you can set the minimum registration period to a lower value.
For a new set, it is beneficial to check how frequently the set actually re-registers. Most sets re-register close to the negotiated period but some ignore it and re-register much more frequently and may cause performance issues on the system.

300 seconds

Enter a value of 0 or 90 to 9999 seconds. 0 will disable the timer. If the device does not respond within the allocated time, the session (call) is torn down.

It is recommended that this be set to a non-zero value unless there is a specific reason to disable it (set to 0). The benefit of this option is that it can help clear calls that get stuck due to signaling errors. If the device responds with a 422 “Session Interval too Small,” you may want to increase the session timer to the value indicated by the device to minimize delays in call setup.

The Session Timer will use the UPDATE message if it is supported by the peer. If not supported we will use ReINVITE messages as described in RFC 4028. The Session Timer refresh is sent at half the Session Timer value. For example, if the value is 120 seconds, then the messaging (UPDATE or ReINVITE) will occur every 60 seconds. To limit extra messaging a larger value (e.g. 3600 seconds) can be used for the Session Timer to eventually cleanup any possible stuck resources.

0 **

Selecting 'Yes' sets MiVoice Business (local), instead of the device, as the Session Timer Refresher (in accordance with RFC 4028). ). Some device will require the MiVoice Business to be the refresher.  Session timer refresh information will be included in Reinvite messages sent by MiVoice Business, as well as in Updates.

No

Enter a value between "120" and "99999" seconds, in increments of 1 second, to define the initial period for SIP outgoing subscriptions.

3600

Enter a value between "120" and "3600" seconds, in increments of 1 second, to define the minimum amount of time that the system maintains incoming SIP subscriptions (for example, message-waiting indications).

300

Enter a value between "50" and "99" percent to define the outgoing subscription refreshment interval. When this percentage of the Subscription Period is reached, the subscription is refreshed.

80

Enter a value between 1 and 30 seconds to define the time the system waits to receive a ringing response before it redirects a call using out-of-service handling.

NOTE: This is an important feature for SIP Wireless or SIP-DECT sets that may lose service temporarily or for resilient solutions that need to make sure the call gets delivered in a reasonable amount of time.

Since most wired SIP phones respond quickly, a timeout value of 2 to 3 seconds is usually enough for basic calls.

In some circumstances the SIP phone may require more time (up to 10 seconds) to start alerting the phone. There is a trade-off between waiting too long (the caller hangs up because they hear no ringback) and too short (the call doesn't get presented to the user and goes to out-of-service handling).

Without the timer, callers to a SIP phone could get a full 32 seconds of silence (if they wait that long) before they are re-routed to some other destination. If Hot Desk PIN Security is in use, the recommended default is 6 seconds.

0 **

Set this option to 'Yes' if an outbound proxy or session border controller is expected to perform outgoing KPML digit collection.

No

Set this option to 'Yes' to force MiVoice Business to request outgoing KPML digit collection from other SIP servers that wish to inject mid-call digits.

No

Read-only, protected field. Each index number represents a unique inward dialing modification rule. The rules are applied in consecutive order; for example, rule 1 is applied before rule 2.

Read-only, protected field. The digits to match at the beginning of the dial string in inbound calls.

Blank

Display-only, protected field. The digit length operator to apply to the incoming call.

Valid operators:

• undefined

• equal to

• less than

• greater than

• greater than or equal to

• less than or equal to  

undefined

Read-only, protected field. The number of digits to match (0-32) at the beginning of the dial string in inbound calls.  

0

Read-only, protected field. The number of digits to absorb (0-32) at the beginning of the dial string in inbound calls.

0

Read-only, protected field. The string to insert at the beginning of the dial string in inbound calls.

Blank

Read-only field. Displays the creation date of the SIP Device Capabilities profile. For a new profile, this field defaults to the current date.

MM DD YY

Enter the name of the person responsible for creating the SIP Device Capabilities profile. For a new profile, this field defaults to "Local."

Local

Read-only field. Displays the MiVoice Business software version number of the SIP Device Capabilities profile. For a new profile, this field defaults to the current software version.

Enter the name of the SIP device using this profile.

Blank

Enter additional information concerning the SIP device using this profile. For example, enter the release date and version number of the SIP device software.

Blank